CUBRID 환경 변수¶

• CUBRID: CUBRID 시스템이 설치된 위치를 지정하는 기본 환경 변수이다. CUBRID 시스템에 포함된 모든 프로그램은 이 환경 변수를 참조하므로 정확히 설정되어 있어야 한다.

• CUBRID_DATABASES: databases.txt 파일의 위치를 지정하는 환경 변수이다. CUBRID 시스템은 $CUBRID_DATABASES/databases.txt 파일에 데이터베이스 볼륨들의 절대 경로를 저장 관리한다. databases.txt 파일 을 참고한다.

• CUBRID_CHARSET: CUBRID 시스템이 데이터베이스의 로캘(언어+문자셋)로 사용할 언어를 지정하는 환경 변수이다. 제품 설치 시 초기 설정 값은 en_US 이며, 언어 이름 뒤에 문자셋을 생략하면 ISO-8859-1(.iso88591)이 기본으로 지정된다. 자세한 내용은 언어 설정 을 참고한다.

  Warning

  데이터베이스를 생성할 때 CUBRID_CHARSET(설치 시 기본값 en_US, ISO-88591 문자셋 사용)을 반드시 지정해야 하며, 문자셋에 따라 문자열 타입의 크기, 문자열 비교 연산 등에 영향을 끼친다. 데이터베이스 생성 시 지정된 문자셋은 변경할 수 없으므로 지정에 주의해야 한다.

  문자셋, 로캘 및 콜레이션 설정과 관련된 자세한 내용은 다국어 지원을 참고한다.

• CUBRID_MSG_LANG: CUBRID 시스템이 명령어 사용법 메시지와 오류 메시지를 출력할 때 사용할 언어를 지정하는 환경 변수이다. 제품 설치 시 초기 설정 값은 없으며, 설정 값이 없으면 CUBRID_CHARSET 의 설정을 따른다. en_US 뒤에 문자셋을 생략하면 ISO-8859-1(.iso88591)이 기본으로 지정된다. 자세한 내용은 언어 설정 을 참고한다.

• CUBRID_TMP: Linux용 CUBRID에서 cub_master 프로세스와 cub_broker 프로세스의 유닉스 도메인 소켓 파일을 저장하는 위치를 지정하는 환경 변수로, 지정하지 않으면 cub_master 프로세스는 /tmp 디렉터리에, cub_broker 프로세스는 $CUBRID/var/CUBRID_SOCK 디렉터리에 유닉스 도메인 소켓 파일을 저장한다(Windows용 CUBRID에서는 사용되지 않는다).

CUBRID_TMP 의 값에는 다음과 같은 제약 사항이 있다.

• unix socket의 path의 최대 크기가 108이므로 다음과 같이 $CUBRID_TMP 에 108보다 긴 경로를 입력하면 에러를 출력한다.

  $ export CUBRID_TMP=/home1/siwankim/cubrid=/tmp/123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
  
  $ cubrid server start apricot
  
  The $CUBRID_TMP is too long. (/home1/siwankim/cubrid=/tmp/123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789)
  

• 상대 경로를 입력하면 에러를 출력한다.

  $ export CUBRID_TMP=./var $ cubrid server start apricot
  
  The $CUBRID_TMP should be an absolute path. (./var)
  

CUBRID_TMP 는 CUBRID가 사용하는 유닉스 도메인 소켓의 기본 경로에서 발생할 수 있는 다음 문제를 회피하기 위해 사용할 수 있다.

• /tmp 는 주로 Linux에서 임시 파일을 저장하는 공간으로, 시스템 관리자가 이 공간을 주기적으로 임의 삭제하는 경우 유닉스 도메인 소켓까지 삭제될 수 있다. 이러한 경우 $CUBRID_TMP 를 /tmp 가 아닌 다른 경로로 설정한다.
• 유닉스 도메인 소켓 파일의 경로 최대 길이는 108인데, CUBRID의 설치 경로가 길어서 cub_broker용 유닉스 도메인 소켓 파일을 저장하는 $CUBRID/var/CUBRID_SOCK 경로의 길이가 108을 넘는 경우 브로커를 구동할 수 없다. 따라서 $CUBRID_TMP를 108이 넘지 않는 경로로 설정해야 한다.

이들 환경변수는 CUBRID를 설치하면서 이미 설정되었으나, 설정을 확인하기 위해서는 다음 명령을 사용할 수 있다.

• Linux

  % printenv CUBRID
  % printenv CUBRID_DATABASES
  % printenv CUBRID_CHARSET
  % printenv CUBRID_TMP
  

• Windows

  C:\> set CUBRID
  

OS 환경 변수 및 Java 환경 변수¶

• PATH: Linux 환경에서 PATH 환경 변수에는 CUBRID 시스템의 실행 파일이 있는 디렉터리인 $CUBRID/bin이 포함되어 있어야 한다.
• LD_LIBRARY_PATH: Linux 환경에서는 LD_LIBRARY_PATH (혹은 SHLIB_PATH나 LIBPATH) 환경 변수에 CUBRID 시스템의 동적 라이브러리 파일(libjvm.so)이 있는 디렉터리인 $CUBRID/lib이 포함되어 있어야 한다.
• Path : Windows 환경에서 Path 환경 변수에는 CUBRID 시스템의 실행 파일이 있는 디렉터리인 %CUBRID%\bin이 포함되어 있어야 한다.
• JAVA_HOME: CUBRID 시스템에서 자바 저장 프로시저 기능을 사용하기 위해서는 Java Runtime Environment (JRE) 1.6 이상 버전이 설치되어야 하고 JAVA_HOME 환경 변수에 해당 디렉터리가 지정되어야 한다. Java 저장 함수/프로시저 환경 설정 을 참고한다.

환경 변수 설정¶

Windows 환경인 경우

Windows 환경에서 CUBRID 시스템을 설치한 경우는 설치 프로그램이 필요한 환경 변수를 자동으로 설정한다. [시스템 등록 정보] 대화 상자의 [고급] 탭에서 [환경 변수]를 클릭하면 나타나는 [환경 변수] 대화 상자에서 확인할 수 있으며, [편집] 버튼을 통해 변경할 수 있다. Windows 환경에서 환경 변수를 변경하는 방법에 대한 상세한 정보는 Windows 도움말을 참고한다.

Linux 환경인 경우

Linux 환경에서 CUBRID 시스템을 설치한 경우는 설치 프로그램이 .cubrid.sh 혹은 .cubrid.csh 파일을 자동으로 생성하고 설치 계정의 셸 로그인 스크립트에서 자동으로 호출하도록 구성한다. 다음은 sh이나 bash 등을 사용하는 환경에서 생성된 .cubrid.sh 파일의 환경 변수 설정 내용이다.

CUBRID=/home1/cub_user/CUBRID
CUBRID_DATABASES=/home1/cub_user/CUBRID/databases
CUBRID_CHARSET=en_US
ld_lib_path=`printenv LD_LIBRARY_PATH`

if [ "$ld_lib_path" = "" ]
then
    LD_LIBRARY_PATH=$CUBRID/lib
else
    LD_LIBRARY_PATH=$CUBRID/lib:$LD_LIBRARY_PATH
fi

SHLIB_PATH=$LD_LIBRARY_PATH
LIBPATH=$LD_LIBRARY_PATH
PATH=$CUBRID/bin:$CUBRID/cubridmanager:$PATH

export CUBRID
export CUBRID_DATABASES
export CUBRID_CHARSET
export LD_LIBRARY_PATH
export SHLIB_PATH
export LIBPATH
export PATH

언어 설정¶

CUBRID 데이터베이스 관리 시스템은 사용할 언어를 CUBRID_CHARSET 환경 변수로 지정한다. 현재 CUBRID_CHARSET 환경 변수에 설정될 수 있는 값의 예는 다음과 같다.

• en_US: 영어(기본값)
• ko_KR.euckr: 한국어 EUC-KR 인코딩
• ko_KR.utf8: 한국어 UTF-8 인코딩
• de_DE.utf8: 독일어 UTF-8 인코딩
• es_ES.utf8: 스페인어 UTF-8 인코딩
• fr_FR.utf8: 프랑스어 UTF-8 인코딩
• it_IT.utf8: 이태리어 UTF-8 인코딩
• ja_JP.utf8: 일본어 UTF-8 인코딩
• km_KH.utf8: 캄보디아어 UTF-8 인코딩
• tr_TR.utf8: 터키어 UTF-8 인코딩
• vi_VN.utf8: 베트남어 UTF-8 인코딩
• zh_CN.utf8: 중국어 UTF-8 인코딩

CUBRID의 언어와 문자셋 설정은 데이터를 쓰거나 읽을 때 영향을 미치며, 프로그램들이 출력하는 메시지에도 해당 언어가 사용된다. 제품 설치 시 CUBRID_CHARSET 의 기본값은 en_US 이다.

문자셋, 로캘 및 콜레이션 설정과 관련된 자세한 내용은 다국어 지원 을 참고한다.

CUBRID 기본 사용 포트¶

접속 요청을 기다리는(listening) 프로세스들을 기준으로 각 OS 별로 필요한 포트를 정리하면 다음과 같으며, 각 포트는 listener 쪽에서 개방되어야 한다.

(*): CAS 또는 CSQL 프로세스가 존재하는 장비

(**): cub_server가 존재하는 장비

서버 프로세스(cub_server)와 이에 접속하는 클라이언트 프로세스들(CAS, CSQL) 사이에서 상대 노드가 정상 동작하는지 ECHO(7) 포트를 통해 서로 확인하므로, 방화벽 존재 시 ECHO(7) 포트를 개방해야 한다. ECHO 포트를 서버와 클라이언트 양쪽 다 개방할 수 없는 상황이라면 cubrid.conf의 check_peer_alive 파라미터 값을 none으로 설정한다.

다음은 각 프로세스 간 연결 관계를 나타낸 것이다.

application - cub_broker
            -> CAS  -  cub_master
                    -> cub_server

• application: 응용 프로세스
• cub_broker: 브로커 서버 프로세스. application이 연결할 CAS를 선택하는 역할을 수행.
• CAS: 브로커 응용 서버 프로세스. application과 cub_server를 중계.
• cub_master: 마스터 프로세스. CAS가 연결할 cub_server를 선택하는 역할을 수행.
• cub_server: DB 서버 프로세스

프로세스 간 관계 기호 및 의미는 다음과 같다.

• - 기호: 최초 한 번만 연결됨을 나타낸다.
• ->, <- 기호: 연결이 유지됨을 나타내며, -> 의 오른쪽 또는 <-의 왼쪽이 화살을 받는 쪽이다. 화살을 받는 쪽이 처음에 상대 프로세스의 접속을 기다리는(listening) 쪽을 나타낸다.
• (master): HA 구성에서 master 노드를 나타낸다.
• (slave): HA 구성에서 slave 노드를 나타낸다.

다음은 응용 프로그램과 DB 사이의 연결 과정을 순서대로 나열한 것이다.

1. application이 cubrid_broker.conf에 설정된 브로커 포트(BROKER_PORT)를 통해 cub_broker와 연결을 시도한다.

2. cub_broker는 연결 가능한 CAS를 선택한다.

3. application과 CAS가 연결된다.

   Linux에서는 application이 유닉스 도메인 소켓을 통해 CAS와 연결되므로 BROKER_PORT를 사용한다. Windows에서는 유닉스 도메인 소켓을 사용할 수 없으므로 각 CAS마다 cubrid_broker.conf에 설정된 APPL_SERVER_PORT 값을 기준으로 CAS ID를 더한 포트를 통해 연결된다. APPL_SERVER_PORT의 값이 설정되지 않으면 첫번째 CAS와 연결하는 포트 값은 BROKER_PORT + 1이 된다.

   예를 들어 Windows에서 BROKER_PORT가 33000이고 APPL_SERVER_PORT 가 설정되지 않았으면 application과 CAS 사이에 사용하는 포트는 다음과 같다.

   • application이 CAS(1)과 접속하는 포트 : 33001
   • application이 CAS(2)와 접속하는 포트 : 33002
   • application이 CAS(3)와 접속하는 포트 : 33003

4. CAS는 cubrid.conf에 설정된 cubrid_port_id 포트를 통해 cub_master에게 cub_server로의 연결을 요청한다.

5. CAS와 cub_server가 연결된다.

   Linux에서는 CAS가 유닉스 도메인 소켓을 통해 cub_server와 연결되므로 cubrid_port_id 포트를 사용한다. Windows에서는 유닉스 도메인 소켓을 사용할 수 없으므로 임의의 가용 포트를 통해 cub_server와 연결된다. Windows에서 DB server를 운용한다면 브로커 장비와 DB 서버 장비 사이에서는 임의의 가용 포트를 사용하므로, 두 장비 사이에서 방화벽이 해당 프로세스에 대한 포트를 막게 되면 정상 동작을 보장할 수 없게 된다는 점에 주의한다.

6. 이후 CAS는 application이 종료되어도 CAS가 재시작되지 않는 한 cub_server와 연결을 유지한다.

CUBRID HA 사용 포트¶

CUBRID HA는 Linux 환경에서만 지원한다.

접속 요청을 기다리는(listening) 프로세스들을 기준으로 각 OS 별로 필요한 포트를 정리하면 다음과 같으며, 각 포트는 listener 쪽에서 개방되어야 한다.

(*): CAS, CSQL, copylogdb, 또는 applylogdb 프로세스가 존재하는 장비

(**): cub_server가 존재하는 장비

서버 프로세스(cub_server)와 이에 접속하는 클라이언트 프로세스들(CAS, CSQL, copylogdb, applylogdb 등) 사이에서 상대 노드가 정상 동작하는지 ECHO(7) 포트를 통해 서로 확인하므로, 방화벽 존재 시 ECHO(7) 포트를 개방해야 한다. ECHO 포트를 서버와 클라이언트 양쪽 다 개방할 수 없는 상황이라면 cubrid.conf의 check_peer_alive 파라미터 값을 none으로 설정한다.

다음은 각 프로세스 간 연결 관계를 나타낸 것이다.

application - cub_broker
            -> CAS  -  cub_master(master) <-> cub_master(slave)
                    -> cub_server(master)     cub_server(slave) <- applylogdb(slave)
                                          <----------------------- copylogdb(slave)

• cub_master(master): CUBRID HA 구성에서 master 노드에 있는 마스터 프로세스. 상대 노드가 살아있는지 확인하는 역할을 수행.
• cub_master(slave): CUBRID HA 구성에서 slave 노드에 있는 마스터 프로세스. 상대 노드가 살아있는지 확인하는 역할을 수행.
• copylogdb(slave): CUBRID HA 구성에서 slave 노드에 있는 복제 로그 복사 프로세스
• applylogdb(slave): CUBRID HA 구성에서 slave 노드에 있는 복제 로그 반영 프로세스

master 노드에서 slave 노드로의 복제 과정 파악이 용이하게 하기 위해 위에서 master 노드의 applylogdb, copylogdb와 slave 노드의 CAS는 생략했다.

프로세스 간 관계 기호 및 의미는 다음과 같다.

• - 기호: 최초 한 번만 연결됨을 나타낸다.
• ->, <- 기호: 연결이 유지됨을 나타내며, -> 의 오른쪽 또는 <-의 왼쪽이 화살을 받는 쪽이다. 화살을 받는 쪽이 처음에 상대 프로세스의 접속을 기다리는(listening) 쪽을 나타낸다.
• (master): HA 구성에서 master 노드를 나타낸다.
• (slave): HA 구성에서 slave 노드를 나타낸다.

응용 프로그램과 DB 사이의 연결 과정은 CUBRID 기본 사용 포트와 동일하다. 여기에서는 CUBRID HA에 의해 1:1로 master DB와 slave DB를 구성할 때 master 노드와 slave 노드 사이의 연결 과정에 대해서만 설명한다.

1. cub_master(master)와 cub_master(slave) 사이에는 cubrid_ha.conf에 설정된 ha_port_id를 사용한다.
2. copylogdb(slave)는 slave 노드에 있는 cubrid.conf의 cubrid_port_id에 설정된 포트를 통해 cub_master(master)에게 master DB로의 연결을 요청하여, 최종적으로 cub_server(master)와 연결하게 된다.
3. applylogdb(slave)는 slave 노드에 있는 cubrid.conf의 cubrid_port_id에 설정된 포트를 통해 cub_master(slave)에게 slave DB로의 연결을 요청하여, 최종적으로 cub_server(slave)와 연결하게 된다.

master 노드에서도 applylogdb와 copylogdb가 동작하는데, master 노드가 절체로 인해 slave 노드로 변경될 때를 대비하기 위함이다.

CUBRID SHARD 사용 포트¶

접속 요청을 기다리는(listening) 프로세스들을 기준으로 각 OS 별로 필요한 포트를 정리하면 다음과 같으며, 각 포트는 listener 쪽에서 개방되어야 한다.

(*): shard CAS와 shard_proxy는 물리적으로 서로 분리되지 않으므로 방화벽에서 포트 개방을 설정하지 않아도 된다. Linux에서 두 프로세스 간 접속은 유닉스 도메인 소켓을 사용한다.

(**): CAS 또는 CSQL 프로세스가 존재하는 장비

(***): cub_server가 존재하는 장비

서버 프로세스(cub_server)와 이에 접속하는 클라이언트 프로세스들(CAS, CSQL) 사이에서 상대 노드가 정상 동작하는지 ECHO(7) 포트를 통해 서로 확인하므로, 방화벽 존재 시 ECHO(7) 포트를 개방해야 한다. ECHO 포트를 서버와 클라이언트 양쪽 다 개방할 수 없는 상황이라면 cubrid.conf의 check_peer_alive 파라미터 값을 none으로 설정한다.

application - shard broker
            -> shard proxy <- shard CAS - cub_master
                                        -> cub_server

• shard broker: CUBRID SHARD 브로커 프로세스. application과 shard proxy를 중계
• shard proxy: CUBRID SHARD 프록시 프로세스. 어떤 shard DB를 선택할 지 결정하는 역할을 수행
• shard CAS: CUBRID SHARD CAS 프로세스. shard proxy와 cub_server를 중계

프로세스 간 관계 기호 및 의미는 다음과 같다.

• - 기호: 최초 한 번만 연결됨을 나타낸다.
• ->, <- 기호: 연결이 유지됨을 나타내며, -> 의 오른쪽 또는 <-의 왼쪽이 화살을 받는 쪽이다. 화살을 받는 쪽이 처음에 상대 프로세스의 접속을 기다리는(listening) 쪽을 나타낸다.

다음은 CUBRID SHARD 구성에서 application과 DB server 사이의 연결 과정에 대해 나열한 것이다. shard CAS와 shard proxy는 CUBRID SHARD를 구동(cubrid shard start)하는 시점에 이미 연결된 상태이다.

1. application이 shard.conf에 설정된 BROKER_PORT를 통해 shard broker에 연결을 시도한다.

2. shard broker는 연결 가능한 shard proxy를 선택한다.

3. application과 shard proxy가 연결된다. shard proxy의 최소, 최대 개수는 shard.conf의 MIN_NUM_PROXY와 MAX_NUM_PROXY에 의해 설정된다.

   Linux에서는 application이 유닉스 도메인 소켓을 통해 shard proxy와 연결된다. Windows에서는 유닉스 도메인 소켓을 사용할 수 없으므로 각 shard proxy마다 shard.conf에 설정된 BROKER_PORT와 MAX_NUM_PROXY를 가지고 계산된 포트를 통해 연결된다.

   예를 들어 Linux에서 BROKER_PORT가 45000이고 MAX_NUM_PROXY가 3일 때 사용하는 포트는 45000 하나면 된다.

   • application이 shard proxy(1)과 접속하는 포트: 45000, shard CAS가 shard proxy(1)과 접속하는 포트 : 없음
   • application이 shard proxy(2)와 접속하는 포트: 45000, shard CAS가 shard proxy(2)와 접속하는 포트 : 없음
   • application이 shard proxy(3)과 접속하는 포트: 45000, shard CAS가 shard proxy(3)와 접속하는 포트 : 없음

   반면, Windows에서 BROKER_PORT가 45000이고 MAX_NUM_PROXY가 3이면 사용하는 포트는 다음과 같다.

   • application이 shard proxy(1)과 접속하는 포트: 45001, shard CAS가 shard proxy(1)과 접속하는 포트 : 45004
   • application이 shard proxy(2)와 접속하는 포트: 45002, shard CAS가 shard proxy(2)와 접속하는 포트 : 45005
   • application이 shard proxy(3)과 접속하는 포트: 45003, shard CAS가 shard proxy(3)와 접속하는 포트 : 45006

   Note

   현재 버전에서 MIN_NUM_PROXY는 사용되지 않고 MAX_NUM_PROXY만 사용된다.

4. shard CAS와 shard proxy는 CUBRID SHARD를 구동(cubrid shard start)하는 시점에 이미 연결된 상태이다. 또한, 각 프로세스는 항상 한 장비 내에 존재하므로 원격 접속이 불필요하다.

   shard CAS가 shard proxy로 연결할 때 Linux에서는 유닉스 도메인 소켓을 사용하지만 Windows에서는 유닉스 도메인 소켓이 없어 포트를 사용한다(위의 예 참고). shard proxy 하나 당 여러 개의 shard CAS가 연결될 수 있다. shard CAS의 최소, 최대 개수는 shard.conf의 MIN_NUM_APPL_SERVER, MAX_NUM_APPL_SERVER에 의해 설정된다. shard proxy 하나가 동시에 연결 가능한 shard CAS의 최대 개수는 shard.conf의 MAX_CLIENT에 의해 설정된다.

5. shard CAS는 cubrid.conf에 설정된 cubrid_port_id 포트를 통해 cub_master에게 DB 서버로의 연결을 요청한다.

6. shard CAS와 DB 서버가 연결된다. Linux에서는 CAS가 유닉스 도메인 소켓을 통해 cub_server와 연결되므로 cubrid_port_id 포트를 사용한다. Windows에서는 유닉스 도메인 소켓을 사용할 수 없으므로 임의의 가용 포트를 통해 cub_server와 연결된다. Windows에서 DB server를 운용한다면 브로커 장비와 DB 서버 장비 사이에서는 임의의 가용 포트를 사용하므로, 두 장비 사이에서 방화벽이 해당 프로세스에 대한 포트를 막게 되면 정상 동작을 보장할 수 없게 된다는 점에 주의한다.

7. 이후 shard CAS는 application이 종료되어도 shard CAS가 재시작되지 않는 한 cub_server와 연결을 유지한다.

CUBRID Web Manager, CUBRID Manager 서버 사용 포트¶

접속 요청을 기다리는(listening) 프로세스들을 기준으로 CUBRID Web Manager, CUBRID Manager 서버가 사용하는 포트는 다음과 같으며, 이들은 OS의 종류와 관계없이 동일하다.

• CUBRID Manager 클라이언트가 CUBRID Manager 서버 프로세스에 접속할 때 사용하는 포트는 cm.conf의 cm_port와 cm_port + 1이며 cm_port의 기본값은 8001이다.
• CUBRID Web Manager 클라이언트가 CUBRID Web Manager 서버 프로세스에 접속할 때 사용하는 포트는 cm_httpd.conf의 listen이며 기본값은 8282이다.